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SimplelTK is a new interface to tine Insigint Segmentation and Registration Tooll<it (ITK) 
designed to facilitate rapid prototyping, education and scientific activities via higli level 
programming languages. ITK is a templated C++ library of image processing algorithms 
and frameworks for biomedical and other applications, and it was designed to be generic, 
flexible and extensible. Initially, ITK provided a direct wrapping interface to languages 
such as Python and Tel through the WraplTK system. Unlike WraplTK, which exposed 
ITK's complex templated interface, SimplelTK was designed to provide an easy to use 
and simplified interface to ITK's algorithms. It includes procedural methods, hides ITK's 
demand driven pipeline, and provides a template-less layer. Also SimplelTK provides 
practical conveniences such as binary distribution packages and overloaded operators. 
Our user-friendly design goals dictated a departure from the direct interface wrapping 
approach of WraplTK, toward a new facade class structure that only exposes the required 
functionality, hiding ITK's extensive template use. Internally SimplelTK utilizes a manual 
description of each filter with code-generation and advanced C++ meta-programming to 
provide the higher-level interface, bringing the capabilities of ITK to a wider audience. 
SimplelTK is licensed as open source software library under the Apache License Version 
2.0 and more information about downloading it can be found at http://www.simpleitk.org. 

Keywords: software design. Insight Toolkit, segmentation, software development, image processing software, 
image processing and analysis 



1. INTRODUCTION 

The proper practice of the scientific method requires the system- 
atic verification of reproducibility of published reports (Popper, 
1934). Ideally, this verification should be performed by indepen- 
dent observers for it to be trustable (Popper, 1968). In the context 
of computational science, the reports of scientific research must 
include the means and the complete details required to enable 
independent groups to fuUy replicate the published results. In 
particular, they should include: data, reports, list of experimental 
parameters, and software. 

Open source software provides public implementations of 
state of the art algorithms, that facilitate the accelerated advance- 
ment of a field, through a more efficient research lifecycle and 
more practical education. The National Library of Medicine's 
Insight Segmentation and Registration Toolkit (ITK) is a leading 
open source software library for biomedical image analysis. Since 
1999, it has been used in fields as diverse as brain registration 
for neuroscience, microscopy image analysis, radiation treatment 
planning, image segmentation for brain tumors, and processing 
of electron microscopy, as well as non-medical applications such 
as satellite imagery and industrial inspection. 

Our fundamental goal in developing SimplelTK was to grow 
the user community of ITK. Whereas direct use of the ITK 
programming interface requires expertise in templated C++, 
SimplelTK was designed to be accessible from a variety of higher 
level languages. Furthermore SimplelTK has a straightforward 



interface that requires no knowledge of the intricacies of ITK's 
templated types. By lowering the bar to access ITK's portfolio 
of image processing algorithms we hope to reach the domain 
scientist and to further the goals of open source and open 
science. 

1.1. THE INSIGHT SEGMENTATION AND REGISTRATION TOOLKIT 

The Insight Segmentation and Registration Toolkit (ITK) was 
originally conceived as open software tools for the analysis of 
the Visible Human Project by the National Library of Medicine 
(NLM) with partnership from six other institutes at the National 
Institutes of Health (NIH). During the initial development the 
mission of ITK was outlined as: a software foundation for future 
research, an archival repository of image processing algorithms, 
a catalog of validation techniques, as well as a platform for 
advanced product development (Yoo et al., 2002). NLM has 
continued to support ITK through Algorithm Adaptors and 
Data Distribution (A2D2) programs and on going maintenance, 
while trying to foster the development of a sustainable open 
source community. In 2010 NLM initiated a major revision 
and refactoring of the toolkit funded by the American Recovery 
and Reinvestment Act. Among the objectives outlined is to 
simplif)' ITK. 

Through the contributions of the ITK community and con- 
tinued funding the scope of ITK has continued to grow. The 
version 4 refactoring separated ITK into a modular structure 
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which now contains over 100 modules. The segmentation algo- 
rithms available in ITK include region growing, level sets, Markov 
random field classifiers, watersheds and other statistical classifiers. 
The registration fi'amework is designed to be modular with 
the distinct parts for a transform, interpolator, transform, opti- 
mizer, and image similarity metric along with support for multi- 
resolution methods. ITK also contains data-structures for spatial 
object, histograms, finite element meshes, quad-edge meshes, 
neural networks, images and narrow band level-sets. There are 
a large number of third party libraries that are supported and 
used for input and output. Additionally there are numerous 
image filters algorithms available including mathematical mor- 
phology, smoothing, deconvolution, distance maps, fast march- 
ing, image fusion, image statistics, geometric filters, and image 
sources among many others. ITK contains a wealth of algorithms, 
interfaces and data-structures to provide a platform for research 
in algorithm development and a collection of image processing 
algorithms. 

The design of ITK focuses on providing a powerful and flexible 
platform to allow for research, experimentation and development 
of algorithms. To that end one of the notable implementation 
details in ITK is the extensive use of C-h-l- templates. The ITK 
image class is a templated structure over both the pixel type as well 
as the image dimension. The pixel type is the data type used to 
represent a pixel. It can be an intrinsic integer or a real number as 
well as an array-like class to represent vector or color pixels. This 
design choice pervades all areas of the toolkit. Image filters must 
be templated over the image type. Also the data structures and 
objects used with the image classes are templated. These struc- 
tures include image iterators, points, and indices. The results of 
this interface design can be seen code Listing 1, taken from the 
ITK Software Guide (Ibanez et al, 2005). 

Notably missing from the design goals of ITK were usability 
and ease of accessibility. 

1.2. WraplTK 

The native wrapping of ITK is performed with a project called 
WraplTK (Lehmann et al., 2006), which was integrated with ver- 
sion 4 into the main source repository. Its goal was to be a direct 
mapping of ITK's interface for languages such as Python, Java 
and Tel. As a direct mapping it attempts to expose all of ITK's 
functionality including the pipeline, template parameters of data 
objects and filters along with ITK's use of pointers to objects. 
WraplTK provides interfaces to many basic ITK objects such the 
basic array, index vector, point and matrix classes. Additionally 
interfaces to the core data object types such as images and trans- 
forms are provided along with iterators and other utility classes. 
Most of these types have template parameters for both dimension 
and value type. The available types in WraplTK make it possible 
to use most of ITK's filters and many of ITK's modular frame- 
works, such as registration, with the native ITK class to specify 
parameters. 

WrapITK's implementation was an evolution of the initial ITK 
wrapping system which used CABLE (Lehmann et al., 2006). 
There are four components to this system CMake (Martin and 
Hoffman, 2003), GCC_XML (http://www.gccxml.org), pygccxml, 
and SWIG (Beazley, 2003). The process is driven by CMake which 



runs GCC_XML to produce an easily parsable description of the 
ITK source code, then uses manually written CMake "wrap" files 
along with Python's pygccxml module to create a SWIG interface 
file and describe how the ITK templates parameters should be 
defined. Next SWIG generates the C-H- code which instantiates 
and wraps the ITK for the targeted language. 

The result is a powerful exposure of the ITK interface, along 
with many of ITK's difficulties and problems. Each templated ITK 
class is instantiated, compiled and wrapped as separate objects. 
So in the target language the correct template parameters must 
be provided as part of the class's name to be constructed. While 
this approach is very much in the style of ITK, many of the 
targeted languages are scripted and typeless, making this extra 
verbosity unnatural and cumbersome. This approach also has a 
very large impact on the size of the WraplTK library and the 
number of symbols in the library. For every ITK class, with every 
combination of template parameter, for each method a wrap- 
per method is needed, which introduces multiple symbols in the 
library that must be loaded into the target language namespace. 
With most of the pixel types instantiated, the WraplTK library 
can be over a gigabyte, can contain nearly 3 million symbols, and 
can take over a minute to load into Python. Also because of the 
size, the large number of configuration options, and the compUe- 
time and configuration options, precompiled binaries are not 
available. 

1.3. OTHER WRAPPING 

ManagelTK was developed to provide wrappers for ITK for 
the .NET languages such as C#, VB.NET and IronPython 
(Mueller, 2007). It was based on the WraplTK infrastructure, 
without the use of GCC_XML or SWIG, instead relying on a 
manual description of properties of ITK classes, with the addi- 
tion of some manually written wrapper classes for key data types. 
Many of the advantages of this interface come from the power 
of .NET including rapid GUI development, support for multiple 
languages, and object browsing in an IDE. However, this wrap- 
ping approach only works with Microsoft Visual Studio on the 
Windows operating system, and properties and methods for a 
new ITK object need to be manually added and updated. Also 
there is no testing generated for the wrapped interface. 

MATLAB (Mathworks, Natick, MA) is a popular commer- 
cial platform for research and prototyping bio-medical image 
processing and other numeric computation algorithms. There 
are several libraries available to access ITK algorithms inside 
MATLAB, although they are not providing a direct access to the 
ITK interface. These include MatlTK (Chu and Hamarneh, 2006) 
and SimlTK (Dickinson et al., 201 1). 

2. DESIGN GOALS 

SimplelTK is designed to reduce the burden of usage and expand 
the ITK user community by simplifying the complexities that 
are frequently encountered when trying to use ITK. Our goal is 
to expose the algorithms in ITK in a readily available format. 
Currently a direct ITK user must be a sophisticated developer 
with computer science skills to be able to compile and combine 
ITK algorithms with their own C-H- code. While applications 
(Osirix, Paraview, SNAPITK, 3D Sheer) are built on top of ITK, 
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36 typedef float InputPixelTy pe ; 

37 typedef float OutputPixelType ; 

38 

39 typedef itk : : Image< InputPixelType , 2> InputlmageType ; 

40 typedef itk :: Image< OutputPixelType , 2> OutputlmageType ; 
41 

42 typedef itk : : ImageFileReader<InputImageType> ReaderType ; 
43 

44 typedef itk : : DiscreteGaussianlmageFilter <InputImageType , OutputlmageType > FilterType ; 
45 

46 FilterType::Pointer filter = FilterType:: New ( ) ; 

47 ReaderType :: Pointer reader = ReaderType :: New () ; 

48 reader— > SetFileName ( argv[l] ); 
49 

50 f ilter-> Setlnput ( reader-> GetOutput ( ) ); 
51 

52 const double gaussianVariance = atof( argv[3] ); 

53 const unsigned int maxKernelWidth = atoi( argv [4] ); 
54 

55 f i 1 1 e r—> S et Variance ( gaussianVariance ); 

56 f i 1 1 er-> SetMaximumKernelWidth ( maxKernelWidth ); 
57 

58 filter->Update 0 ; 
59 

60 typedef unsigned char WritePixelType ; 

61 typedef itk:: Image < WritePixelType, 2> WritelmageType ; 

62 typedef itk : : RescalelntensitylmageFilter < OutputlmageType, WritelmageType RescaleFilterType ; 

63 RescaleFilterType:: Pointer rescaler = RescaleFilterType:: New ( ) ; 
64 

65 re s c al er— > SetOutputMinimum ( 0 ); 

66 re s c al er— > SetOutputMaximum ( 255 ); 
67 

68 typedef itk :: ImageFileWriter < WritelmageType > WriterType ; 

69 WriterType :: Pointer writer = WriterType :: New () ; 

70 writer— > SetFileName ( argv [2] ); 
71 

72 rescaler— > Setlnput ( f i 1 1 e r -> GetOutput ( ) ); 

73 writer— > Setlnput ( re s c a 1 er-> GetOutput ( ) ); 

74 writer->Update () ; 

Listing 1 | A typical ITK example with templates, which reads an image, runs a Gaussian convolution then writes it back out to disk. 



internally using ITK data structures and algorithms and exter- 
nally exposing certain filters for image manipulation, users of 
these applications are not direct users of ITK. We wish to expand 
the user base, by making the programming interface accessible 
to non-computer scientists such as domain scientists, biomedical 
engineers and mathematicians. 

Interactive scripting and programming environments such as 
the Python's SciPy environment (Jones et al, 2001), MATLAB and 
The R Project for Statistical Computing are popular choices for 
initial prototyping and experimentations. Scripting languages are 
easily accessible to more people than C-H-. 

The first complication a new user of ITK encounters is the 
lack of a binary distribution or compiled software. They must 
download and compile ITK from the source code, which requires 
development tools such as a compilers and CMake which may be 
new to the user. This requirement is a large initial hurdle, and 
problems are frequently encountered as shown by the many help 
requests on the ITK community mailing list. 

A second common difficulty is dealing with the ITK's advanced 
C-H- templates. ITK uses templates for both an image type's 



pixel type and the dimension, and the algorithms are templated 
over the image types. The naive usage of these features require 
the developer to determine static types used at compile time. 
The code needed to create a basic program is excessively long 
and verbose with basic programs requiring numerous C-H- type 
definitions. Handling multiple pixel types or image types can 
result in even more bulky and complicated code with nested case 
statements for template function dispatching. 

A third problem is complications arising from the ITK 
pipeline. When filters in a pipeline get executed, the number 
of times they get executed, and the implicit buffering occurring 
between filters can all result in performance issues. Common 
problems include data or meta-data being out of date, excessive 
memory usage due to filters buffering output, and unnecessary 
re-execution of filters. In many cases a naively assembled ITK data 
pipeline can perform worse than sequentially executing filters. 

2.1. SURVEY AND ARCHITECTURAL REVIEW BOARD 

Kitware conducted a survey of the ITK and related computer 
vision and medical imaging communities. A variety of mailing 
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lists were queried for users to voluntarily fiU out a survey includ- 
ing ITK, VTK, R imaging group, Linkedin, etc. Feedback was 
obtained on commonly used tools, applications and requirements 
for image processing. There were 253 total participants of which 
45 participants had never used ITK and 54 were uncomfortable 
using C++. 

The survey produced several important conclusions. First, a 
pre-compiled, installable package greatly increases the likelihood 
user uptake. Second, 1 dimensional images are not important 
with only 4 participants saying it would likely to be used. Third, 
for each pixel type the group was asked to rate its priority from 
"Not important" to "Essential." Every pixel type had a minimum 
of 25% of the participants saying it was at least a "High Priority." 

When asked questions about preferred programming lan- 
guages, programming styles, object oriented vs. procedural, fea- 
tures of ITK used or resource requirement, there was a lack 
of clear consensus. So we concluded that it is important for 
SimplelTK to be flexible in its usage. 

To obtain more specific guidance on the design an Advisory 
Review Board (ARB) was assembled consisting of 9 members 
from academia, corporations and government agencies. During 
the design process pseudo code of interfaces were reviewed. The 
ARB was another important voice in the design process, giving 
opinions on best approaches and guidance on prioritizing design 
philosophies. 

2.2. GOALS 

For a successful project there are certain software engineering 
goals that must be achieved for maximum impact. Firstly, the 
software should appeal to the greatest audience possible. This 
goal suggests that SimplelTK must be cross platform and support 
modern desktop operating systems such as Microsoft Windows, 
Apple OS X, and GNU Linux. As observed in our survey, a vari- 
ety of languages should be supported and the framework should 
easily be extendible to other target languages. Also, to make it eas- 
iest for potential users to try the software, there should be binary, 
downloadable packages available. 

Reliability and quality of the software is also of high impor- 
tance. If a potential user downloads the software, and the first 
thing they try does not work, they may never invest the time to 
resolve the issue. To achieve reliability, automatic and manual 
testing is a must. The coverage of the code needs to be high to 
build confidence in the quality and reliability of the software. 

Given that we want to expand the ITK community beyond 
those who are comfortable with the current complexities of ITK, 
certain features should be hidden to enable clearer access to the 
core algorithms available in ITK. A common complaint about 
ITK is the difficulties with using the templates for image and filter 
algorithms. To address this complaint an important objective is to 
present a template-less abstraction or typeless layer to the native 
ITK interface that implicitly handles the ITK templated types. We 
set the larger goal of not exposing any templates in the SimplelTK 
interface. 

Another challenge in our design is to provide a procedural 
interface to the algorithms, while still providing a object oriented 
interface for those that prefer it. Therefore the interface design 
needs to be flexible so that it can support multiple usage styles. 



There are many aspects of ITK that we would like to retain. The 
algorithms still needed to be at the high performance standard 
that ITK currently has as a compiled C++ library. And we still 
would like support for the flexible multi-threaded infrastructure 
when the filtering algorithms are executed. The survey partici- 
pants placed a high priority on the large number of pbcel types 
available in ITK. Therefore we must support this wide variety of 
pixel types including color images and vector component images. 

The initial mission of ITK included providing a platform 
for algorithm development, SimplelTK goals focus on providing 
usable algorithms. So the building block that ITK provides for 
algorithm development such an image iterator, adaptor, neigh- 
borhood algorithms and other utilities and interfaces are not 
designed to be included in the SimplelTK interface. This limi- 
tation should not exclude SimplelTK from being a platform for 
new algorithm development. For example new methods can be 
developed that are a composite of other algorithms. 

Lastly, while ITK is an biomedical segmentation and registra- 
tion library, it explicitly does not contain any visualization. That 
is a user can not view an image with ITK alone. Viewing an image 
requires an external program or library. However for SimplelTK 
to be part of an interactive environment convenient visualization 
of intermediate images is required. 

3. IMPLEMENTATION 

We implemented SimplelTK as an interface on top of ITK, built 
as a C++ library. This interface is then wrapped for a variety of 
targeted languages. The SimplelTK interface is functionally com- 
plete and fuUy encapsulates ITK. In other words SimplelTK can be 
used independently without any direct calls to ITK. This interface 
was designed from the ground up to be easy to use and intuitive, 
as well as to take advantages of advanced language features and 
convenience. 

The goals for this project were high, and some of them seemed 
in conflict. The challenges of presenting a procedural interface 
for the highly object oriented and templated ITK library while 
stiU preserving robust support for multiple image dimensions 
and pixel types was the essence of the problem in designing 
SimplelTK. Based on our motivations and goals a number of 
choices were made. 

3.1. DECISIONS 

3.1.1. No exposed pipeline 

One of the first decisions was that we were not going to expose 
ITK's demand driven pipeline. We decided to hide the pipeline 
because errors in using the pipeline are quite common to new 
users. Without the pipeline, results of operations are immediate 
so there is no chance that an image is out of date or missing infor- 
mation. Users can simply call the methods needed to set a filter's 
parameters then execute the filter. The overhead required to con- 
nect, manage and update filters is removed from the interface. 
Also, with filters executing immediately, the object oriented and 
the procedural interfaces can be closely related. 

3. 1.2. Use SWIG for wrapping 

One of the fundamental goals of SimplelTK was to provide lan- 
guage bindings for different languages such as Python, Java, and 
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C#. Due to the large number of language targets, a single uni- 
fied tool for all languages was required for maintainability. The 
Simplified Wrapper and Interface Generator (SWIG), is open 
source and a powerful development tool for wrapping C++ with 
numerous high-level programming languages. SWIG has support 
for over 20 target languages. It is capable of parsing basic C++ 
interfaces and generating glue code to connect the target lan- 
guages to the interface. The result is generally a direct mapping 
of a methods from the target language to an associated method in 
the C++ interface. 

WrapITK uses SWIG to interface ITK with other languages. 
But the complexity of the templated programming used in 
ITK means that SWIG cannot directly wrap ITK. Instead 
WrapITK requires additional tools to explicitly specify the inter- 
face of ITK in a format that SWIG can understand to wrap 
certain instantiations of the templated ITK interface. SimplelTK's 
simplified interface is designed to be directly wrappable by SWIG. 

3.1.3. Parameter types 

ITK uses a variety of array-like types such as arrays, vectors, 
indexes, sizes, points and offsets. These types have template 
parameters such as dimension and value type which makes them 
dependent on the type of the image, resulting in dozens of array- 
like types in the native ITK interface. SWIG has built in support 
for many C++ Standard Template Library (STL) objects such as 
stdr.vector and std::Ust and provides specialized interfaces for tar- 
get languages. For example SWIG can provide an interface to a 
stdr.vector in Python similar to its own list or tuple type along with 
implicit conversions. This feature greatly improves the interaction 
in the target language, giving the interface a native feel. Because 
of the goal to create a template-less layer free from compile-time 
parameters, SimplelTK uses std::vectors for array-like parameters 
for its interface. However, for the targeted scripting language it 
may appear as native arrays. 

3. 1.4. Hide smart pointers 

Pointers and explicit memory management are elements of C++ 
that preclude it from being considered a high-level language 
compared to scripting languages like Python. The smart pointer 
design pattern is a combination of implicit reference counting 
for objects along with an interface of a standard pointer so that 
objects can be automatically deleted when no longer referenced. 
Thus, they reduce the burden of explicit memory management. 
While smart pointers are used in ITK, they are not simple enough 
for SimplelTK as they may introduce a new concept in target 
languages. Many languages provide a direct object type, not a sep- 
arate pointer type that refers to the object. The burden of a direct 
approach in C++ is that implicit deep copies of objects occur dur- 
ing assignments and passing arguments by value. We decided that 
SimplelTK would provide direct image, filter and transformation 
objects but not provide the undue burden of implicit copying. 

3. 1.5. Template-less layer 

The template-less or typeless layer concept's goal is to hide ITK's 
template parameters from the user. A common suggestion was 
to simply consider all images as 32-bit or 64-bit real numbers. 
However, this approach can cause unacceptable memory use and 



performance penalties. Consider starting with an image that is 
an 8-bit and 4 gigabytes. Converting to a 64-bit type would use 
eight times the memory now requiring 32 gigabytes of memory 
for its representation. This monolithic choice changes the nature 
of working with an image from one that can be done on a laptop 
to one that requires a large server. Additionally, the users surveyed 
demanded the flexibility to use a variety of pixel types. 

Therefore the template-less layer concept requires that 
SimplelTK images all have the same external type and interface, 
unlike ITK. The details of dealing with the different ITK template 
parameters is hidden so that the user can generically manipu- 
late any image. An image's pixel type and dimension are handled 
by SimplelTK internally and not directly exposed to the user, 
unlike ITK which requires the user to explicitly determine them at 
compile-time. At runtime a PixellDValue, in the form of an inte- 
ger and enumerated type is used to represent a pixel type, which 
along with the image dimension are intrinsic run-time attributes 
of the SimplelTK image. 

3. 1.6. Facade interfaces 

The facade design pattern is a software design pattern to present 
the user with an simplified interface to a larger body of code 
(Gamma et al, 1995). This approach is how SimplelTK encap- 
sulates ITK filters and data objects, where the body of code 
encapsulated is the set of template parameters for a class. Our 
facades internally use ITK objects and call ITK methods, so there 
is very little additional code. The facade code provides a template- 
less layer to instantiate and dispatch to the correct templated 
ITK code. Additional code is used to make the objects of the 
facade behave natively instead of requiring smart pointers and 
converting between the templated ITK array-like types and STL 
objects. 

3. 1.7. Image buffer access 

The ability to easily import and export images into SimplelTK 
is a critical feature. It enables the interfacing between multiple 
image processing libraries. We chose to allow the direct expo- 
sure of an image's buffer via a raw pointer at the C++ interface. 
This pointer provides efficient direct access, however its use is 
inherently unsafe. Therefore it is not directly exposed in wrapped 
languages. Instead our goal is to expose a native array interface to 
the buffer in the target language, such as numpy for Python. 

3.2. THE DESIGN OF THE SIMPLEITK IMAGE 

The image class is at the heart of SimplelTK. It is the most com- 
monly used class and has been specially designed to provide a 
natural and intuitive user interface across multiple target lan- 
guages. We followed our principles for intuitive interface driven 
design by writing numerous example code blocks and discussing 
tradeoffs with the ARB. 

From an interface perspective, the handling of the life of an 
object, i.e., how the object is constructed, copy and destroyed, 
is a key aspect of developing an intuitive interface. Because we 
chose not to expose smart pointers, we use a completely differ- 
ent approach from ITK's New factory method. Our approach is 
simple and translates to other languages seamlessly. We simply 
directly expose the Image class's constructors and destructor with- 
out the restrictions applied in ITK. The reasons ITK uses the 
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New factory method include: adding flexibility to override a class' 
implementation and enforcing smart pointers use by preventing 
stack based allocation. Our approach to the SimplelTK interface 
does not allow our classes to be directly overridden but still allows 
ITK class overrides to occur internally. As we encourage the direct 
use of our Image class, the smart pointer motivation is moot as 
well. An Image is able to be default constructed, as an image of 
size zero. An image of any dimension or pixel type is considered 
to be empty if its size is zero. The common constructor methods 
take parameters for the size of the image along with the pixel type 
and support the option for the number of components per pixel. 
The dimension of the image is determined by the number of com- 
ponents used for size. How Images are copied is closely related to 
their constructors, but the relationship between the SimplelTK 
interface and ITK objects needs to be described first. 

The SimplelTK Image interface presented, utilizes the facade 
design pattern in conjunction with the private implementation, 
"pimpl" pattern (Sutter, 2000). It is a facade in that it provides 
a unified interface for multiple ITK classes and template param- 
eters. The single SimplelTK Image class provides an interface to 
ITK's Image, Vectorlmage, and LabelMap classes and supports 
multiple dimensions and pixel types. However, the SimplelTK 
Image class is not polymorphic, i.e., it is not a virtual base class 
and does not contain virtual methods. Instead it relies on an 
internal pointer to a private class in the "pimpl" pattern to pro- 
vide a unified polymorphic interface to ITK's Image class. The 
"pimpl" image has an abstract base class for the unified interface 
with templated derived classes to implement the specifics. This 
"pimpl" image fully encapsulate ITK's templates and instantiates 
all the ITK image classes. A call from the SimplelTK interface to 
an ITK image is quite efficient and direct despite the complexity 
of the patterns used. A call to the SimplelTK image's method, calls 
the same method in the "pimpl" Image through the polymorphic 
interface, which then calls the ITK method. This dispatch method 
is direct and free from any conditionals. The SimplelTK Image 
only contains a pointer to the "pimpl" image which only contains 
a smart pointer to ITK Image. This implementation provides an 
efficient interface with low overhead. 

Our interface also allows for direct copying and assignment of 
the Image class in an optimized manner. From a user perspec- 
tive, the availability of optimized copy methods is generally all 
that needs to be known. However, we have optimized these meth- 
ods by using a form of lazy evaluation through a copy-on-write 
(COW) policy. This policy is a key component that allows for 
an efficient implementation while removing pointers from the 
interface. Ironically, COW is implemented by using ITK's smart 
pointers. When a copy of a SimplelTK Image occurs, a new ITK 
smart pointer to the image is created and stored. This new smart 
pointer increases the reference count contained of the ITK Image. 
When there is a write request to the SimplelTK Image, the refer- 
ence count is checked; if it is not 1, then a deep copy is performed 
of the bulk image data. This approach enables the SimplelTK 
Image to be passed by value without the overhead of implicitly 
copying the bulk image data. 

Our user survey and ARB discussions were inconclusive in 
determining a limited set of important pixel types to implement. 
As adding more image or pixel types does not increase the number 



of methods in the SimplelTK interface, we do not limit the types 
enabled. Currently we have up to 26 different pixel types available 
including scalars, multi-component vectors, complex as well as 
label maps implemented with the run length encoded LabelMap 
classes. Fully implementing these type does not have an adverse 
effect on usability or run-time. It does however increase the 
demands on the system requirements for compiling the library. 
As the goals for SimplelTK focus more on usability of the inter- 
face then ease of building, it was determined to be a reasonable 
tradeoff. Additionally, we settled for only supporting 2 and 3 
dimensional images. Interest by the users in higher dimensional 
images was limited. 

The Image interface was also customized for C-H-, Python, 
R, Java and C# to provide additional syntactic enhancements to 
make language integration as easy as possible. These enhance- 
ments include features such as operator overloading, advance 
subscripting, and utilizing weak typing of return values in many 
scripting languages. 

The resulting image class provides a simple and easy to use 
interface that fully encapsulates the complexities of ITK. Among 
the things that are hidden include templates for both the image 
dimension and pixel type as well as multiple image classes. Details 
such as smart-pointers, memory management and copy seman- 
tics are also removed and replace with a straightforward C-H- 
interface. This standard interface can be directly wrapped by 
SWIG, thus providing a conventional interface for different target 
languages. 

3.3. THE DESIGN OF THE SIMPLEITK FILTERS 

Among the objectives which drove the filter interface design of 
SimplelTK included removing the dependency on the image type 
at compile-time, the removal of ITK's data driven pipeline as 
well as providing a flexible interface which has an object ori- 
ented and procedural interface. With the template-less image class 
designed and the decision to use STL's stdr.vector as parameters 
whose length is dependent on the image dimension, the interface 
was rather straight forward. Determining which types to use for 
filter method parameters was a difficulty when it was the same 
type as the image's pixel type. GenericaUy using the double type 
resolved this issue. The double is a superset of all scalar pixel 
types except 64-bit integers, and for vector pixel types the scalar 
value is replicated for all components. Listing 2 can be used as a 
reference. 

In ITK, the pipeline needs to be explicitly updated before 
results can be examined. This update initiates the examination 
of the dependencies in the pipeline to determine the necessary fil- 
ters to execute. After the Update method of a filter is called the 
results in the output are valid and can now be examined. Without 
the pipeline, a filter is executed immediately, so the method name 
Execute was chosen to illustrate the difference. Filters which have 
secondary results, such as a number of iterations or a measure- 
ment of error are problematic for the procedural interface as 
functions naturally only return a single value. The solution was 
to add "measurements" only to the filter classes. An alternative 
approach, to make these available through the procedural inter- 
face was have them as arguments to the procedural methods. 
However doing so would result in too many arguments, and 
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2 classFilter 

3 { 

4 public: 

5 

6 std::string GetName () const ; 

7 

8 std:: string ToString () const ; 

9 

10 Self &SetPai ameter (double pixelValue ) ; 

11 double GetParameter 0 const ; 
12 

13 Self &SetDimensionParameter ( std : : vector<unsigned int > dimValue ) ; 

14 std : : vector<unsigned int> GetDimensionParaeter () const; 
15 

16 double GetMeasurement 0 const ; 

17 

18 Image Execute ( const Image &imagel); 

19 Image Execute ( const Image &image 1 , double pixel Value , std :: vector< unsigned int> dimValue); 
20 

21 }; 
22 

23 Image F i 1 1 e r ( const Image &image 1 , doublepixe 1 Value = 0, std :: vector < unsigned int> dimValue = 

defaultValue); 



Listing 2 | A prototypical example of a SimplelTK filter interface. 



passing by reference or pointer is not portable across differing 
languages. 

Defining the behavior of a filter is more complicated than spec- 
ifying the desired interface for the template-less filter. For each 
filter decisions must be made about the input types supported as 
well as the image type produced. The goal is to have filters support 
as many image types as possible. Even when the ITK filter does 
not directly support vector images, the SimplelTK infrastructure 
can execute the ITK filter on each component independently. For 
determining the output image type there are a couple general 
policies that occur. The first and most common is defining the 
output image type the same as the input. This is sensible for many 
filters including mathematical morphology, image grid manipu- 
lations, and label image manipulations. For other filters having 
a fixed output type is sensible. For example filters which output a 
mask such as thresholding, always output a unsigned 8-bit integer, 
while distance field filters produce 32-bit floating point numbers. 
Consideration must include limiting the number of instantiated 
filters of one type to a reasonable number, to prevent excessive 
compilation and library size from excessive permutation, so in 
general there is no selection of the output type. 

Those filters which take two image as input required spe- 
cial consideration for how to handle the multiple types. In ITK, 
filters that are binary functors such as the addition and subtrac- 
tion operators, have 3 template parameters corresponding the 
two inputs and the single output. This approach makes ITK very 
flexible by aOowing conversion to occur simultaneously with the 
operation. Languages have different type promotions schemes, 
and certain overflow and conversions are explicitly undefined in 
C-H-. Therefore we decided that most of the binary filters require 
the inputs to both be of the same type as well as the resulting 
output. So we do not do any implicit conversion or promotion, 
thereby requiring the user to explicitly cast the inputs to be the 



same type. SimplelTK does have the ability for filters to accept 
multiple images of differing types and to use the correct ITK fil- 
ter templates based on these input types. These filters are called 
dual image filters in SimplelTK. They have been used sparingly 
due to size constraints when the computation validity of multiple 
types is not in question. The types of filters where this feature is 
used include filters with masking and overlays. The group of fil- 
ters which allow the user to select the output type such as casting, 
camping, and resample also use the dual dispatch infrastructure. 

By choosing to remove ITK's pipeline architecture from 
SimplelTK there are numerous simplifications that we have taken 
advantage in our design. Among the ITK features SimplelTK 
omits are the advanced details of memory management occur- 
ring in the pipeline such as releasing data, and running filters 
in place. They are not relevant, since SimplelTK has an immedi- 
ate execution model that lacks pipeline buffering. ITK's interface 
for the ProcessObject, which is the basis for all filters, consists of 
over 40 public methods for manipulating the pipeline and man- 
aging the inputs and outputs. All these methods are irrelevant 
for SimplelTK's Execute method approach. Omitting them sim- 
plifies the interface for each filter class. Among the features still 
relevant is the monitoring of progress and events; these features 
are scheduled for the next release of SimplelTK, version 0.8. 

3.4. IMPLEMENTATION DETAILS 

The design of the interface was not done in isolation from 
the implementation. Extreme software development method- 
ologies were use to continuously test and regularly integrate 
features into a stable version. The goals and the design of 
the interface presented immense software engineering problems 
that had not been addressed before with ITK. Initially there 
were doubts that maintainable code and infrastructure could 
be developed to create a template-less layer for a significant 
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part of ITK's filters without unmaintainable, manually created 
code. Our resulting implementation uses advanced C++ template 
meta-programming to perform compUe-time execution of code 
generation, as well as traditional code generation based on the 
description of filters. The details in this section are completely 
hidden from a user of SimplelTK, and are relevant to those exam- 
ining the internals of SimplelTK or those who wish to learn the 
novel techniques used for similar projects. 

3.4.1. Overview 

SimplelTK is implemented with more than just static code. It is 
a complex sequence of code generation and compilation to pro- 
duce the C++ interface, followed by wrapping with SWIG for the 
target languages (see Figure 1). The manually written common 
code of SimplelTK consists of the meta-programing infrastruc- 
ture for the template-less layer and the core data structures such 
as the image and the transform classes. Also, a few of the filters 
and the reading, writing and image display interfaces are written 
by hand. As of SimplelTK 0.7.1, the SimplelTK C++ interfaces 
for 245 image filters are automatically generated from manually 
written descriptions. 

3.4.2. Code generation 

After experimenting and iteratively improving manually written 
filter interfaces, it was immediately apparent that a solely manu- 
ally written interface would take excessive time to develop, lead 



to an inconsistent interface, and be unmaintainable. Due to the 
requirement of maintaining a consistent interface among a large 
number of filters, automatic source code generation became the 
natural choice. Code generation allows the developers to focus on 
writing the generator and the description at a higher level than 
the immediate interface. 

Each generated filter in SimplelTK is described by a JavaScript 
Object Notation (JSON) file. The JSON file structure is a 
lightweight data format popularized by JavaScript programming 
for the web, which is easy for both humans and computer software 
to read and write. The JSON description contains the essence of 
an ITK filter. A filter description contains expected named fields, 
such as name, template_type, number _of_inputs, pixel_types, and 
output_pixel_type, with values, as well as more generic fields 
which can contain C++ code to be inserted into the template. 
The output_pixel_type is frequently more that just a static value 
by containing meta-programing to transform the input type to 
the output. Additionally, there is the member sections which con- 
tains the description for each filter parameter so that it can be 
stored in the SimplelTK facade and translated into the typed ITK 
filter. There is also an optional section to describe measurements, 
and how to update the member variable from the results of the 
ITK filter. 

For normal image filters previously mentioned portion of the 
JSON description can generally be written in just a few moments 
from a similar example. The time consuming part in writing a 
JSON description is the tests section. This section contains input 
image file names, the values of parameters, and either a hash of 
the expected output or a baseline image to compare a test against. 
By including this section we are able to generate tests for each 
language to verify usability and functionality of the filter with dif- 
ferent image types. Automatic testing is critical to developing a 
robust interface that is proven and reliable. 

The generator of the source code is a text based program, 
which processes a set of text inputs and produces source code. 
Lua is a powerful, portable, fast, and lightweight scripting lan- 
guages (lerusalimschy et al, 2006). We chose it as the language 
for the source code generator script because its small size makes 
it easily included as part of the SimplelTK source and com- 
piled during the build process. The generator script is derived 
from the Lua "Text Template Expand" example (http://lua- 
users.org/wiki/TextTemplate) combined with an publicly avail- 
able JSON parser. This system uses template files which contain 
and inlined Lua expressions all of which are evaluated into strings. 
The scope of the Lua expressions include variables from the cur- 
rent scope in the JSON description file. There are template files 
for filters of types such as ImageSources, Binary FunctorFilters, and 
DuallmageFilters. 

3.4.3. Template meta-program and typelists 

The crux of the problem for the template-less layer is the abil- 
ity to map the runtime pixel type information, PixellDValue, 
available from SimplelTK's Image to the compile-time template 
parameters in ITK and vice versa. Template meta-programming 
in C++ is the use of templates to perform compile-time execu- 
tion to generate code. SimplelTK uses a concept called "Typelists" 
to operate on list of types, PixellDs, which represent the types 
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FIGURE 1 I Data flow diagram of SimplelTK's build process. Boxes 
represent data, while ovals are important processes. 
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of pixels. Specifically these lists have compile-time operations to 
append, merge, intersect, search, traverse and perform permu- 
tations of selections from two lists (Alexandrescu, 2001). The 
runtime ID of a pixel type, PixellDValue, is the index in the 
global InstantiatedPixellDTypeList type, which is a Typelist of all 
the available pixel types. There are a variety of groups of PixellDs 
declared as Typelists such as integer, real and vector. The JSON 
description of a filter describes the valid input pixel types by 
performing meta-programming operations on these Typelists. 

The compile-time mapping of the run-time PixellDValue to 
an instantiated function with the image as a template parameter 
is more problematic. The compile-time mapping of the PixellD 
to the scalar PixellDValue can and must be done on all instanti- 
ated types. On the other hand the templated functions can only 
be instantiated with the parameters that are specified via Typelists. 
Otherwise the code may not be valid. 

The mapping of the run-time PixellDValue to an instan- 
tiated member function is done with an abstraction called a 
MemberFunctionFactory. This factory has a method which maps a 
PixellDValue and image dimension to a member function pointer 
of an instantiated member function over the associated ITK image 
types. These functions are registered into the factory by passing a 
PixellD Typelist and the dimension. Additionally the factory has a 
templated object which knows how to get the address of the mem- 
ber function, enabling the compile-time traversal of the Typelist 
to instantiate the member function. With the member func- 
tions stored in the factory, they are indexable by the PixellDValue 
at run-time. This MemberFunctionFactory is the heart of the 
dispatch system used to implement SimplelTK's templateless 
layer and is an important software engineering innovation for 
dispatching run-time mappings to ITK types. 

3.4.4. Automated documentation 

Without documentation to accompany filters and algorithms, the 
interface of SimplelTK would be unusable. Duplicating the effort 
to describe each algorithm and parameters with what has already 
been done in ITK would be a foolish task. Doxygen is the de facto 
standard tool for generating reference manuals of a programming 
interface from annotated source code (http://www.doxygen.org). 
It is used as the source code annotation throughout ITK and 
SimplelTK. For all the manually written SimplelTK infrastructure 
and facade interfaces the annotations are written in the source 
code. Automated utilities have been developed to insert docu- 
mentation strings from ITK into the JSON filter description files. 
These documentation fields are then incorporated into the gen- 
erated source code as well as used for wrapped target language's 
online documentation. Currently the ITK documentation some- 
times contains C++ implementation details or other features only 
available in native ITK. In the future ITK's documentation may 
be further annotated to note the relevance of different sections 
to allow better integration with SimplelTK and other external 
projects. 

4. EXAMPLES 

4.1. MULTI-MODAL VENTRICLE SEGMENTATION 

Segmentation of the human brain lateral ventricles is a com- 
mon task in the study of brain anatomy and its diseases. Changes 



in the volume of cerebrospinal fluid and the shape of the cere- 
bral ventricles are associated with a number of diseases including 
hydrocephalus (Brandt et al., 1994) and schizophrenia (Staal 
et al, 2000). 

In this example we use SimplelTK's VectorConfidence 
Connected filter (Ibafiez et al, 2005) to segment an MRI data 
set from the Neuroimage Analysis Center's Multi-modality 
MRI-based Atlas of the Brain (Halle et al, 2013). This filter 
begins with user-selected seed points then iteratively grows a 
region based on the similarity of the local vector image statistics. 
To create a vector image we combine the MRI Tl and T2 images 
into a single vector image. 

We developed this script interactively in an IPython Notebook 
(Perez and Granger, 2007) session. We implemented custom dis- 
play functions called showimg and showimg3d, which allow for 
the easy tiled display of multiple slices. For display we export the 
tiled slices to numpy and utilize matplotlib for inline display in the 
IPython notebook. 

First we read the Tl and T2 brain images and create unsigned 
char version for display (see Listing 3: lines 5-10). Taking advan- 
tage of SimplelTK's Python array slicing, extracting axial slices 
from the MRI volumes is simple (see Figure 2 and Listing 3: 
lines 13-14). Then from the original Tl and T2 volumes we cre- 
ate a vector volume using SimplelTK's Compose function (see 
Listing 3: line 18). 

For initializing the segmentation of the cerebral ventricles we 
start with 2 seed points, one each side (see Listing 3: line 21). 
For visualization purposes, we create a seed volume, based on the 
dimensions of the Tl volume. Setting the seed voxels to 1 is simple 
with SimplelTK's array indexing (see Listing 3: line 25-29, and 
Figure 3). 

To display our segmentation we can create a contour of it and 
overlay that on the Tl volume (see Figure 4 and Listing 3: line 
43-47). 

Finally using a volume tenderer we can visualize the lateral 
ventricles segmentation in 3d (see Figure 5). 

4.2. MICROSCOPY SEGMENTATION 

Many modalities of microscopy acquire images at high resolu- 
tion over large areas and can result in very large data sets. The 
Connectome Project at Harvard's Center for Brain Science is one 
example (Seyedhosseini et al, 201 1). 

To illustrate the computation efficiency and the effective- 
ness of using SimplelTK on larger real world problems, this 
example demonstrates a segmentation of an electron microscopy 
dataset. Ion-abrasion scanning electron microscopy (lA-SEM), is 
an image acquisition technique from the combination of tradi- 
tional scanning electron microscopy acquired on a sample block 
with a focused ion-beam used to mill the block with nano-meter 
resolution. The method has been used for whole cell imaging 
(Murphy et al, 2011). 

The dataset chosen is a volume of 100 nm gold beads used 
to analyze the procedures and methods for data acquisition (see 
Figure 6). It was collected by the Biophysics Section and Electron 
Microscopy Core, Laboratory of Cell Biology at the National 
Cancer Institute and is publicly available on a MIDAS data server 
at the NLM (http://placid.nlm.nih.gov). The dataset was acquired 
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1 import SimplelTK as sitk 

2 from showimg import showimg , showimg3d 
3 

4 # Load the MRI volumes 

5 img.Tl = s it k . Readlmage (" Data / nac- brain— atlas - 1 .0/ volumes / Al _grayT 1 . nrrd " ) 

6 img_T2 = s it k . Readlmage {" Data / nac- brain- atlas - 1 .0/ volumes / Al _grayT2 . nrrd " ) 
7 

8 # Convert the volumes to 8— bit grayscale 

9 img_Tl_255 = s i tk . Cast ( s i tk . Re s c ale Inte nsi ty ( img_Tl ) , sitk . sitkUIntS ) 

10 img_T2_255 = s i tk . Cast ( s i tk . Re s c ale Intens i ty ( img_T2 ) , sitk . sitkUIntS ) 
11 

12 # Extract and display an axial slice from each volume 

13 yslice.Tl = img.Tl _255 [ : . 1 1 5 , : ] 

14 yslice_T2 = img_T2_255 [ : , 1 1 5 , : ] 

15 showimg ( y slice _T 1 , dpi=30, t i 1 1 e =" 1 1 image " ) 

16 showimg( yslice_T2 , dpi=30, t i 1 1 e t2image " ) 
17 

18 # Create a vector volume from Tl and T2 

19 img.multi = sitk . Compose(img_Tl , img_T2) 
20 

21 # Create 2 seed points for the region finding 

22 seeds = [ [112,116,125], [1 10,120,132] ] 
23 

24 # Create a seed point volume 

25 seedimg = sitk . Image(img_Tl . GetSize () , sitk . sitkUInt8 ) 

26 seedimg . Copyinf ormation (img.Tl ) 

27 seedimg [ seeds [ 0 ] ] = 1 

28 seedimg [ seeds [ 1 ] ] = 1 

29 seedimg = sitk . BinaryDilate ( seedimg , 3) 
30 

31 # Display the seed point volume 

32 showimg3d( s i tk . LabelOverlay ( img_Tl _255 , seedimg), 

33 zslices = range ( seeds [0][2] - 3 , seeds [ 1 ] [2] + 3 , 3), 

34 dpi = 15, title ="initialseed" ) 
35 

36 # Perform the region based segmentation 

37 seg = sitk . VectorConfidenceConnected ( img_multi , seeds, numberOf Iterations =2 , multiplier =4.5) 
38 

39 # Apply a median filter to the segmentation 

40 seg = sitk . BinaryMedian ( seg . [3,3,3]) 
41 

42 # Display an overlay image with a contour of the segmented ventricle 

43 overlayed = s it k . LabelOverlay ( img.Tl _255 , s i t k . LabelContour ( seg ) ) 

44 mysize = img.Tl . GetSize () 

45 showimg3d( overlayed, y s li c e s = range ( 1 00 , mysize [ 1 ] - 1 00 , 1 5) , 

46 z s 1 i c e s = range { 1 00 , mysize [2] - 1 00 , 1 5) , dpi=30, t i 1 1 e =" segmentation " ) 
Listing 3 | A Pytiion script using SimplelTK for the multi-modal segmentation of the lateral ventricles. 




FIGURE 2 I Axial cross sections of T1 (left) and T2 (right) MRI of a brain. 



at 5 nm square voxels with a volume size of 1003 x 1003 x 296 
pixels resulting in a 284 megabyte volume. 

The goal of this segmentation is to identify each distinct 
gold bead by creating a unique label for each gold bead. The 



segmentation occurs primarily in two steps: first identifying the 
individual beads (see Listing 4: lines 9-16) and second growing 
the seeds (see Listing 4: lines 26-27). This sequence of process- 
ing was developed in an interactive python session making use of 
SimplelTK's Show method to visualize intermediate results. It was 
then converted into a single script to assist with batch processing 
and parameter exploration. 

The method first uses thresholding to identify the high inten- 
sity gold, then uses mathematical morphology to separate the 
beads of at least 13 pixels (65 nm) in diameter. Next, each isolated 
part is given a unique identifier using the connected components 
algorithm. The watershed from markers algorithm available in 
ITK (Beare and Lehmann, 2006), is a multi-label greedy region 
growing algorithm subject to the penalty of the feature image. 
The individuated gold components are combined with an addi- 
tional marker for the background. This marker image is used in 
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FIGURE 4 I Axial and coronal cross sections withi the resulting ventricle segmentation shown as a green contour. 




FIGURE 5 I Volume rendering of segmented ventricle. 




conjunction with an edge image for the watershed algorithm. The 
SimplelTK code is easy to foUow, brief and executes 16 ITK fil- 
ter to perform its task. Many of those filters are invoked through 
overloaded operators for comparison and arithmetic. 

The resulting segmentation consists of over 9000 seg- 
mented gold beads (see Figures 7 and 8). Segmentation is 
just one of many steps in the process of quantitative anal- 
ysis. SimplelTK provides facilities for basic statistics in the 
LabellmageStatisticsImageFilter. However, for this study custom 
shape analysis was implemented in C++ within ITK's LabelMap 
framework, illustrating the complementary nature of SimplelTK's 
and ITK's interfaces. When implementing new algorithms ITK 



FIGURE 6 I Slice from the gold bead volume with 5nm pixel resolution. 

The dense lOOnm gold beads are bright while the embedded resin is dark. 



can be the best tool to use, while interactively exploring existing 
algorithms for a solution may be better suited to SimplelTK. 

4.3. SIMPLEFILTERS IN 3D SLICER 

The SimplelTK infrastructure can also be used as a way to inte- 
grate ITK into applications. Many image processing applications 
are designed in a modular fashions so that modules or extensions 
can be created to add new functionality. A frequent objective is 
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I import SimplelTK as sitk 
2 

3 img = s i t k . Readlmage { "GoldSnmlnLensA . mrc" ) 

4 sitk. Sliow ( img ) 
5 

6 median_img = s i tk . JVIedian ( img , [1,1,1]) 

7 s i tk . Sliow ( median.img , "In- Median 1 " ) 
8 

9 m = median.img > 160 

10 # Grayscale is more efficient for this case, and produces the same results 

II m = sitk . GrayscaleErode (m, 6) 
12 m = sitk.GrayscaleDilate(m, 2) 
13 

14 s i tk . Show( s i t k . LabelOverlay ( img ,m) , "Mask") 
15 

16 markers = sitk . ConnectedComponent(m, fullyConnected = False ) 

17 del m 
18 

19 # increment all initial makers and add hg marker 

20 markers += s i tk . Cast ( markers ! =0 , markers . GetPixellD () ) 

21 # make a bg maker with I value 

22 markers += s i t k . Cast ( median.img < 50, markers . GetPixellD () ) 

23 s i tk . Show( s it k . LabelOverlay ( img , markers ) , "Markers") 
24 

25 grad = s i tk . GradientMagnitudeRecursi veGaussian ( median_img , median_img . GetSpacing ( ) [0 ] ) 

26 ws = s i tk . MorphologicalWatershedFromMarkers ( grad , markers, 

27 markWatershedLine = False , fullyConnected = False ) 

28 ws -= sitk . Cast (ws==l , ws . GetPixellD () ) 
29 

30 si tk . Show( s it k . LabelOverlay ( img , ws ) , "Segmentation") 

31 sitk.WriteImage(ws."gold_seg. mha" ) 

32 slice=150 

33 sitk.WriteImage(sitk.LabelOverlay( img ,ws) [: ,: , slice] , "gold.seg . tiff") 

34 sitk. Writelmage(img[:,:, slice], "gold, tiff") 



Listing 4 | Example Pytiion script using SimplelTK to segment gold beads with the watersheds algorithm. 



to integrate ITK's important algorithms into an end user appli- 
cation with a graphical user interface (GUI). When trying to 
directly integrate ITK with applications, there are common prob- 
lems encountered that SimplelTK can resolve. Interfacing an 
application's data types with the templated ITK types requires 
dealing with template parameter instantiation and run-time dis- 
patching. Also, for each filter or algorithm important parameters 
and default values need to be determined. SimplelTK can help 
with these and other difficulties to enable rapid integration of a 
large number of ITK filters into a application. 

3D Slicer is in modular image computing platform used for 
quantitative analysis in medical image computing and clinical 
research (Fedorov et al., 2012). It is a free and open source appli- 
cation with support for numerous biomedical imaging formats 
and functionality such as automatic interactive segmentation, 
registration, and visualization. It is built upon a variety of open 
source software to provide core functionality such as visualiza- 
tion, GUI support, and script. It has a modular architecture to 
support custom plug-ins. Despite 3D Slicer including ITK in 
its C-H- backend, the burden of creating a module for a large 
number of ITK filters was too great, so many of ITK's basic image 
processing algorithms were not available to end users. 

The SimpleFilters module in 3D Slicer was created to provide a 
basic GUI to the image filters available in ITK through SimplelTK. 
During the course of a single week at a National Alliance of 



Medical Image and Computing (NAMIC) project week, with the 
support of various member of the developer community, we cre- 
ated an initial implementation of the module encorporating over 
200 SimplelTK image filters with GUIs for their parameters. 

The module was written in Python to take advantage of the 
ability to generate a string and evaluate that string at runtime. By 
using this run-time capability with a few hundred lines of code, 
we were able to implement code to generate a GUI for the param- 
eters and to execute each filter. This module was created without 
any filter specific code or compile-time code generation, but by 
reading SimplelTK's JSON descriptions files to obtain the param- 
eters. The calls to configure filters for execution were constructed 
at runtime from strings. Also the documentation strings in the 
JSON are used for mouse quick tips and hover overs. The module 
uses SimplelTK and its template-less layer for runtime type dis- 
patching, so all image types are supported without additional case 
or switch statements. The SimpleFilters module has been incor- 
porated into 3D Slicer and is part of the binary distribution with 
version 4.3. 

The JSON filter descriptions in SimplelTK contain the essence 
of ITK. They provide a standard to describe the parameters 
for algorithms, along with their default values and documen- 
tation. In addition to the interface and language bindings that 
SimplelTK provides, these descriptions are another valuable asset 
when integrating ITK into applications. They can dramatically 
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FIGURE 7 I Gold bead segmentation results on the same slice as 
Figure 6. Each identified bead has a unique color transparently overlaid the 
original image. 




FIGURE 8 I Volume rendering of colorized labeled gold bead 
segmentation. 



reduce the implementation time and increase the number of 
algorithms that can be made available. 

5. DISCUSSION 

The SimplelTK interface with wrapping for additional languages 
is a new and easy way to use ITK's image processing algorithms 
that wiU make these algorithms available to a wider audience of 
domain scientists. A number of features of ITK are hidden and 
the bulk of the interface has been simplified. Currently approx- 
imately 250 algorithms are available through SimplelTK for 
interactive exploration in a number of scripting and prototyping 
environments. 

SimplelTK has already gone through several releases during 
development. The most current release available is 0.7. Orel. As 
of this writing there have been over 7000 binary downloads of 
SimplelTK on SourceForge. This number does not include those 
who have built SimplelTK from the source code repository or are 



using it from an integrated application. The SimplelTK official 
website (http://www.simpleitk.org) contains more information 
about how to get started using SimplelTK. 

5.1. FUTURE WORK 

While the foundations of ITK have been integrated into the 
SimplelTK interface for classes such as images, transforms and 
interpolators and the infrastructure for source code generation 
for filters has been implemented, much of the work for ITK's 
registration framework is yet to be done. Some ITK registration 
methods are ITK filters and can easily be integrated as part of the 
current framework. The modular registration framework in ITK 
version 3 and the latest version, v4, present new problems which 
require novel design solutions. 

Additionally, there are features in ITK that still need to be 
incorporated in to the SimplelTK interface such as progress 
reporting and call-back methods. While SimplelTK currently 
contains over 250 image filters, we are always looking for feed- 
back from our user community for what additional ITK filters 
should be priorities in future work. Many of the unincorpo- 
rated ITK filters are not commonly used. So when the SimplelTK 
interface is tested, bugs in ITK may arise or other inconsisten- 
cies may be discovered in ITK's interface. These issues must 
be addressed and fixed in ITK and slow the development of 
SimplelTK. 

ITK is a very large toolkit consisting of millions of lines of code. 
The SimplelTK interface is highly customized and not designed 
to expose all of ITK. The design goals of SimplelTK have been 
for a robust, reliable, and elegant interface to ITK. To that end 
we have focused on the template-less layer to the image class and 
image filters. There are many additional data structures that could 
be added to the interface including histograms and quad-edge 
meshes. However, we wish the presented interface to be the best 
possible. To that end some portions of ITK may be avoided to 
maintain a high standard until there is broad ITK community 
support. 

The number of the languages which SimplelTK is wrapped 
for is large and includes Python, Java, C#, Ruby, Lua, Tel and 
R. Developing and maintaining unique features and "syntactic 
sugar" such as advanced subscripting and native buffer interface 
for all languages is too large of a task. We seek the on going 
support of the ITK community to support these features and lan- 
guages. Specifically, in the near future we hope to add native Java 
array integrations with SimplelTK image buffers and improve 
swig's wrapping for the R language to handle enumeration types 
correctly. 

5.2. CONCLUSION 

SimplelTK is a new user-friendly software interface to the image 
processing algorithms available in ITK. Through the use of inno- 
vative software engineering combined with disciplined testing 
practices, SimplelTK makes a large portfolio of reliable open 
source imaging algorithms available to a broad range of scientific 
communities. The end goal of this work is not the SimplelTK soft- 
ware itself Rather the goal is to aid research over a wide range of 
scientific fields by improving accessibility and reproducibility for 
state of the art image analysis algorithms. 
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